REMARKS 

Claims 1-44 are pending in the application. Claims 1, 40, 41, and 43 are independent 
claims. Claims 1-44 stand rejected by the examiner. Assignee traverses the instant claim 
rejections. 

Examiner's Interview 

Assignee's representatives would like to thank examiner Sheng-Jen Tsai for the 
courtesies extended to assignee's representatives (Charles Shorb, Timothy Wilson, Fonda 
Daniels, John Biernacki, and Brett Squires) during the telephone interview on May 18, 2007. 
The interview discussed the cited references Daynes (USPN 6,343,339) and Ofer (USPN 
6,691,194). The office action's statement on page 7 "Therefore, it would have been obvious for 
one of ordinary skill in the art at the time of Applicant's invention to recognize that benefits of 
encapsulation of both lock status data and reader data as a single unit for atomic operations, as 
demonstrated by Ofer, and to incorporate it into the existing scheme disclosed by Daynes to 
further [reduce] the pitfalls of deadlock or starvation situations." During the interview, assignee 
respectfully disagreed that Ofer can be combined with the teachings of Daynes because, inter 
alia, Daynes expressly teaches away from such combination. See Daynes at column 8, lines 37- 
42. Additionally, Ofer is limited to hardware processors and does not provide for multiple 
executing entities such as threads. (See Ofer at column 3, lines 27-32.) The interview further 
discussed Daynes with respect to claim 1 and that claim 1 is directed to handling state, whereas 
Daynes is directed to changing modes and not states. (See Daynes at column 4 lines 1-4 and the 
abstract of Daynes.) Assignee respectfully requested that the examiner contact the undersigned 
attorney at the telephone number listed below, if the examiner is of the opinion that the instant 
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application is in condition for disposition other than allowance. The remarks and the 
amendments contained herein further summarize the interview. 

Rejections - 35 U.S.C. § 103 

Claims 1-27 and 32-44 stand rejected under 35 U.S.C. § 103 as being unpatentable over 
U.S. Patent No. 6,343,339 to Daynes ("Daynes") in view of U.S. Patent No. 6,691,194 to Ofer 
("Ofer"). Claims 28-31 stand rejected under 35 U.S.C. § 103 as being unpatentable over Daynes 
in view of Ofer further in view of U.S. Patent No. 6,480,918 to McKenney et al. ("McKenney"). 
These rejections are traversed. 

Claim 1 is directed toward a memory for storing a computer-implemented shared locking 
data store for handling multiple executable entities' access to at least one resource. Claim 1 
recites (in combination with its other limitations) encapsulation of both lock status data and the 
reader data in the shared locking data store allows a hardware atomic operation to operate upon 
both the lock status data and the reader data as a single unit for determining how access to the 
resource is to be handled. 

The Daynes reference and the Ofer reference (whether viewed alone or in combination) 
do not disclose, teach or suggest such limitations of claim 1 . The Daynes reference defines the 
locking mode according to how the lock is accessed, for a read operation the locking mode is a 
read mode and for a write operation the locking mode is a write mode. The Daynes reference 
then defines the lock state as the set of the values of each of the owners of a the lock. (See 
Daynes column 8 lines 25-36.) The method and apparatus disclosed by Daynes uses a dedicated 
bitmap for each locking mode. When read and write locking modes are used, a lock state 
contains a read bitmap and a write bitmap. (See Daynes column 15 lines 2-5.) The method and 
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apparatus disclosed by Daynes then uses a lock manager, which maintains an associative Table 
of Immutable Lock States, and reliance on resources having redundant lock states to decrease 
memory consumption and processing costs on the system using the method and apparatus. 
When two resources have the same lock state the method and apparatus disclosed by Daynes will 
decrease memory consumption and processing costs on the system by using the same read and 
write bitmaps for both resources. (See Daynes figure 4.) However, if no redundant lock states 
are present the method and apparatus of Daynes will actually increase the memory consumption 
and processing costs on the system because read and write bitmaps must be created for every 
resource, and the system must continue to maintain the Table of Immutable Lock States. 
Therefore the method and apparatus disclosed by Daynes ties system performance directly to the 
occurrence of redundant lock states. In contrast and as recited in claim 1, the lock data is 
encapsulated into a single atomic operation such that memory consumption and processing costs 
on the system decrease regardless of whether or not redundant lock states are present. 

Furthermore, the method and apparatus disclosed in Daynes and which utilize state locks 
to lock resources is based on tasks, not threads. Tasks can be limited programmatically by the 
application. This is a requirement of Daynes to appropriately size the lock state tables in the case 
of the bit-field approach, which would be using the atomic operations to change state. To map 
this onto threads, the maximum possible threads at any one time becomes problematic as this is 
greater than the space provided in a single atomic instruction. Further, the method and apparatus 
disclosed in Daynes and which utilize state locks to lock resources requires the enumeration of 
the task to be unique, a requirement for the creation and maintenance of the Table of Immutable 
States. Attempting to map operating threads to a limited number of tasks slots in a unique 
identifier fashion within the Table of Immutable States space becomes problematic. 
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With respect to the Ofer reference, the Ofer reference is directed toward a method and 
apparatus for improving performance in system where multiple processors contend for control of 
a shared resource. The Ofer reference defines the term shared resource according to a resource's 
visibility to the multiple processors. (See Ofer column 1 lines 15-25.) Further, Ofer limits access 
to the shared resource to a single processor. (See Ofer column 3 lines 66-67 and column 4 lines 
1-20.) Accordingly the method and apparatus disclosed in Ofer does not allow for multiple 
executable entities' access to be concurrent with respect to a resource. Claim 44 has been 
amended herein to further clarify this distinction. Several other of the dependent claims also 
clarify this distinction. For example, claim 3 describes determination of access to the resource, 
and claims 8 and 9 respectively describe the rules mechanism associated with allowing both 
shared access (e.g., any number of read requests) and exclusive access (e.g., only one writer). 

Because the cited references do not disclose the limitations of claim 1, assignee 
respectfully asserts that the rejection be withdrawn and that claim 1 be allowed. Independent 
claims 40, 41, and 43 recite similar limitations as claim 1. Accordingly, assignee respectfully 
asserts that the rejections for these claims be withdrawn and that the claims be allowed. 

[Continued on the next page] 
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CONCLUSION 

For the foregoing reasons, assignee respectfully submits that the pending claims are 
allowable. Therefore, the examiner is respectfully requested to pass this case to issue. 



Respectfully submitted, 



JohryV. Biernacki 
Reg/No. 40,511 

ioms DAY 

North Point 

901 Lakeside Avenue 

Cleveland, Ohio 44114 

(216)586-3939 
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